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Overview 

Online Trading (Edge) 
What it does 

- Provides PW Edge customers the ability to enter, correct and view equity orders over the 
Internet. 

- Allows Brokers to view and correct customer originated trades through existing systems 
(DORS & BOE). 

- Delivers the cornerstone suite of business rules for future order and trade processing systems 
(ConsultWorks, New Allocation System). 

Business Benefits 

Meets competitive requirements. 

Phasing 

- Pilot 1Q'99 

- Full Rollout TBD 

Project Plan 

- Xxxxxxxx. mpp using Edge template to coordinate with that group. 
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Notes to Driver Level Pictorial 

Revisions 

8/20/98 

Moved Log and Assign Reference # processes out of the main processing path. 

Whether these will be physically separate programs or logically separate (code within Driver) TBD. 

See pictorial on these processes later in this document 

Previous comments not implemented 

Additional processing modules, for example, "Assign investor code" should be shown in processing path. 
This follows a guideline recommending a flat long hierarchy. 

Issue here is that an arbitrarily long process path is not best practice for CICS. A link is expensive. Modularization 
for the sake of modularization should be avoided. A processing path of 7 programs would be at the upper end of best 
practice. 

An ASR Guideline is to make the task path "as short as possible". To accomplish this, the suggestion is to 
"add a store". Adding a store, in this case is recommended to be accomplished by writing to a queue, which will 
then write to multiple queues. 

Best practice is to write the 3 queues as designed in Alla's picture. Writing a queue to write a queue is a great deal of 
overhead and should only be used in cases where extreme CICS performance is required 

A single commarea definition is required for each unique processing path. 

In previous applications, a single commarea with re-definitions and ample filler to avoid re-sizing has been used. 
The ASR Guidelines differ from this solutioa 

A single commarea with re-definitions is the way to go. The routing logic using this single commarea should be 
done as efficiently as possible. Not a long series of Cobol "if* statements. An efficient table will allow update of the 
path as needed and handle routing as efficiently as possible. 

Specifically for ECI, multiple entry points are not advised. This would translate into multiple programs and thus 
multiple PPT entries. 



Previous comments still outstanding 
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Message Processing Path - Notes. 

A CICS maintained Data table - defines Processing Path for all Trading Events loaded at the 
PLT Time. 

Revisions 

Changed from in-core table 

From Bill Restemeyer email 8/28/98: 

Recommend a "CICS maintained Data Table. 11 This backs up the data (and any dynamic 
changes) on disk and is therefore available to batch jobs. The only I/Os are at initial open of the 
file and when changes occur. Reading the data table will provide basically the same response- 
time as reading an in-core table. 

There is another advantage: the programmer uses standard CICS file access commands (like 
EXEC CICS READ) and treats the data table as if it were a dataset. 

Corrected table to remove "Validate" from description. 
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Validate Order Process Notes 

This process is approved to be a driver, like Notify. 

Method of linkage is a different commarea only used to communicate between the driver and its sub-programs. 

Returns data from Reference Data read to verify rules in commarea. Returns this info to Edge user. 
If price > $5 a share, commarea then contains the price 
If account verified, commarea contains the short name 
If symbol verified, commarea contains the name 
Investor code 

Revisions 

Rules to ensure Validate does not grow out of its scope: 

Validate cannot store (except commarea or tsqueue) or route. 
Validate can Read only, not write. 

Previous comments not implemented 

TSQueues have been identified as a technique to store data between tasks. By extension, this technique is the 
recommended solution for the same purpose within tasks 

Within a task commarea should be used. In TOR/AOR environments, the entire commarea gets shipped back and 
forth. In this single region area, commarea is more efficient. Within a task, TSQueue is much more overhead than 
the commarea. Additionally, the issue of making this queue unique has not been solved. 
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Validate Cancel Process Notes 

Cancel process is approved to be a driver, like Notify. 

Method of linkage is a different commarea only used to communicate between the driver and its sub-programs. 
Links to shared module OLTP3100 - Generic Validation Module for Cancel/Replace Request 

Common Routines for all types of Cancels: 

• Check Order Exists, Check Open Share Quantity 

• Assign Error Code/MSG, Set Update POD flag 'YESVNO' 

• Assign Error Code/MSG, Set Update POD flag 'YES'/ NO' 

Will read D030 or TDB, whichever is ready 1 st . Eventually TDB will be used when available. 

Revisions 
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Business Rules Parameters Notes 

Parameter Driven Business Rules - allows: 

• Flexibility 

• Customization by different Presentation Layer 

• Provides override capability by Account, Branch, Division, etc. 

Data Model Logical/Physical is in Erwin - contact Martha Sandlain. 

All rules in this result set are "ANDed". 

Does not handle complex rules - code will be used for this. 

Only exception to these rules is the tbd "OVERRIDE" capability for an account, user, etc. which will have priority 
and thus override the rules. - will be documented later as developed. 

Business rule links to program 

In the event user links to a non-existing program, driver program will detect (and handle) a CICS error condition 
and reject the transaction. 

New rules are added using the front end screens in each region (test, QA). After user signoff the same changes must 
be repeated in production, during non-trading hours. The expected volume of non-emergency changes is so low that 
this manual process is seen as the most cost-effective solution. 

Revisions 



Added Product Type column (all currently "Equity") and a row with Policy Group "ALL" to business Rules result 
set 
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Business Rules Trading Notes 

• Pictorial illustrates a few examples of Flexible Validation Process 
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Error and Response Determination Process (including Notify) Notes 

Possible notifications from this system: 

EDGE 

Intrusive alert to broker 

Intrusive alert to EDGE Service Center 

Print Order Drop Copy at»the branch 

Print at the Command Center Console in case of system failure 

CapMkts 

None of the above 

Under some circumstances, drop copy to London 
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Notify Process Notes 
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Log and Assign Reference Process Notes 

• Allows for Audit Trail 

• Allows for various Reports 

• Allows for OLT built test simulator to measure Performance, Stress Testing, as well as parallel 
testing/comparison 

• This log key works in a Sysplex environment. 

• Entries into a Log Data Stores will be done at all Entry points between PL and OLT Trading Component, as 
well as at all the Asynchronous Points (ex. write to MQ) 
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Confirm/Submit Process Notes 

Confirm Process perforins the following: 

• Maintains a State of a WEB application by checking against POD, if request doesn't exist on POD, reject goes 
back to Presentation Layer 

• Maintains Data Integrity by checking against POD, if request has been modified - difference between stored in 
POD and received from Presentation Layer 
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Intraday Credit and Position Load/Check Process Pictorial 
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Intraday Credit and Position Load/Check Process Notes 



This implements a business rule only applicable for Retail/EDGE clients. 
Other processing presentation layers, not yet tied into OTP will not use this. 
For example CapMkts trading systems won 't check this. 

While the Intraday DB2 data store is unavailable, EDGE customers will be unable to trade, since their balances 
cannot be checked. 

This requirement is another reason that the OTP process must be synchronous, not async. 
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Assign Order Reference # Process Notes 
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Recovery Background Process Pictorial 
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Recovery Background Process Notes 

Runs in background (CICS), every # of minutes/seconds (from VC business rules) 

Not in processing path 

Before being written to MQ, this process puts outgoing message on recovery log for replay. 

PLT Time Release Processes: 

1 Turn MQ Trigger On - 7 am (business days only) 

2. Turn MQ Trigger OFF at 3:^9 PM (business days only) 

3. Reinitialize Running Daily Balance ?? am(business days only) 

4. Obtain Settlement Date 7 am (business days only) 

5. Start Recovery Process 

Question to be reviewed with user by ATuretsky: 

On DORS, orders > 2 mins are sent to Perodi to determine action. 

What should OTP do with Edge. There is nobody to notify, since the user cannot be reached. 
BOE has a similar issue. 

The solution needs a business decision, followed by a technical implementation. 
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Program Ranges 
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Program List 
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Program List Notes 
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Cleanup/POD Process Notes 



C:\unzipped\Documents\OLTP Technical Design Documentdoc 

Page 35 



DRAFT 



J* 

CO 



H 



a; 
*> 

06 

CD 

-♦— > 
O 
D 
+-> 

o 



H 
O 

< 



.2 
o 
o 



On 
On 
On 



a 
c 

3 



o 
o 

s 

<L> 

E 



o 

a 

.1 

to 

Q 

73 
o 

I 



9 

c 
E 

3 

O 

! 

a. 



7/2/ 1 999 ASR/OLT Architecture Review A. Turetsky 



Inquiry Function Notes 
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Order/Cancel Message Format Attached as Vol 2 on MIS-3 
:\OLT\P LINPUT\CANCORD.XLS 
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Order/Cancel Messaae Format Attached as Vol2 on MIS-3 
:\OLT\PLINPUT\CANCORD.XLS 
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